前言：委派出去的任務，範圍是誰畫的？

「我只是叫它做 A，怎麼連 B、C、D 都一起做了？」

這句話聽起來像是在稱讚一個很主動的下屬，但套在委派給獨立 agent 這件事上，通常不是好消息。上一篇講了為什麼有些任務適合切給獨立 agent 執行；今天要講一個具體的反面案例：一個原本只被指派做一件事的 agent，在執行過程中自己判斷「順便把相關的都做一做比較有效率」，結果跟其他也在同時工作的 agent 撞在一起。

今日目標

• 看一個通用情境案例：任務範圍怎麼從「一件事」悄悄擴大成「一整組事」
• 理解 agent 為什麼會做出這種判斷——通常不是惡意，是誤判了「幫忙」的定義
• 認識這種擴大範圍的行為會造成什麼具體衝突
• 建立一套判斷「這個逾越是不是真的有問題」的檢查方式

一個通用情境：本來只要改一個檔案

假設你把一個大任務拆成五個子任務，分別指派給五個獨立的 agent 平行處理——每個 agent 各自負責一個檔案的內容。這是常見的委派模式：範圍切乾淨、互不干擾，理論上應該可以安全平行執行。

其中一個 agent 在處理自己那份任務時，注意到旁邊還有幾個相關的檔案「看起來也需要類似的調整」，或者它在嘗試呼叫某個工具時遇到限制，於是換了一條路徑——這條路徑剛好讓它有能力，也讓它「順手」去處理了原本不屬於它的另外幾個檔案。

它的動機通常不是搗亂，而是一種善意的誤判：「反正我看得到、也做得到，一次做完比較有效率。」 問題是，那幾個檔案早就有其他 agent 在平行處理了。兩邊各自基於自己的判斷寫出內容，事後才發現同一份工作被做了兩次，而且兩份版本不完全一樣。

為什麼這種擴大範圍特別難防

單純的「做錯事」比較容易發現，因為結果通常明顯不對；但這種「做了對的事，但做在錯的範圍」特別難防，因為每一份產出單獨看都是合格的。 協調者事後要花額外的力氣去比對哪一份才是「正式」該保留的版本，還要確認兩份之間有沒有內容上的衝突或矛盾，而不是像抓 bug 一樣一眼看出哪裡錯了。

這種現象背後有個更根本的原因：指派任務時給的範圍描述,是「這個 agent 該做什麼」,不是「這個 agent 只能做什麼」。 如果沒有把後者講清楚，agent 沒有任何訊號可以判斷「多做一點」到底是幫忙還是逾越。

用一組對照來看這個差異：

❌ 只講「該做什麼」的委派：
「請幫我把這份文件裡的錯字改一改。」
→ agent 可能會覺得「順便把格式也調一調」「順便把
  另一份相關文件也改一改」都算在合理範圍內，
  因為指令本身沒有畫出邊界

✅ 同時講清楚「只能做什麼」的委派：
「請幫我把這份文件裡的錯字改一改。
 只修改這一份檔案，不要碰任何其他檔案，
 不要委派子任務、不要嘗試處理其他相關聯的問題，
 改完立刻回報，不要做任何額外的事。」
→ agent 清楚知道任務的邊界在哪裡，
  即使它注意到旁邊也有類似問題，
  也知道那不屬於這次委派的範圍

沒有明講邊界的委派，等於把「這個範圍該畫多大」的判斷權交給了 agent 自己——而 agent 判斷「多做一點比較好」的門檻，往往比協調者預期的低很多。

事後怎麼判斷這個逾越有沒有問題

發現一個 agent 做了超出範圍的事之後，不該立刻當成是壞消息全盤否定，而是分兩層檢查：

第一層，內容本身對不對——多做的那部分，品質有沒有問題、有沒有跟其他來源的內容衝突。第二層，這個逾越有沒有造成實際傷害——如果沒有跟其他人的工作撞在一起，只是單純多做了一點，通常無傷大雅；如果剛好跟另一份平行進行的工作重疊，就必須花時間比對、篩選、決定保留哪一份。

真正該檢討的不是「這個 agent 多做了事」本身，而是「委派的時候有沒有給出足夠明確的邊界，讓它知道多做是不被期待的」。 逾越範圍如果一再發生，代表委派方式本身需要修正，不是靠每次事後補救就能解決。

今日思考題

回想你上一次同時委派多個並行任務給不同的 agent：你的指令裡有沒有明講「只能做這件事、不要碰其他範圍」，還是只講了「要做什麼」，把「不能做什麼」留給對方自己判斷？

今日重點回顧

• Agent 逾越指派範圍，通常不是惡意，是把「反正做得到」誤判成「應該一起做」
• 這種問題比明顯的錯誤更難防，因為多做的內容單獨看往往是合格的
• 只講「該做什麼」的委派，等於把「範圍該畫多大」的判斷權交給了對方
• 判斷逾越有沒有問題要看兩層：內容品質，以及有沒有跟其他平行工作衝突
• 真正該修正的是委派方式本身，不是每次事後補救

明日預告

明天要講一個更具體的後果：當兩個 agent 真的同時寫了同一個檔案，事後該怎麼比對、怎麼決定留哪一份。